|
Domain-specific multimodeling〔 〕 is a software development paradigm where each view is made explicit as a separate domain-specific language (DSL). Successful development of a modern enterprise system requires the convergence of multiple views. Business analysts, domain experts, interaction designers, database experts, and developers with different kinds of expertise all take part in the process of building such a system. Their different work products must be managed, aligned, and integrated to produce a running system. Every participant of the development process has a particular language tailored to solve problems specific to its view on the system. The challenge of integrating these different views and avoiding the potential cacophony of multiple different languages is ''the coordination problem''. Domain-specific multimodeling〔 is promising when compared to more traditional development paradigms such as single-language programming and general-purpose modeling. To reap the benefits of this new paradigm, we must solve the coordination problem. This problem is also known as the fragmentation problem in the context of (Global Model Management ). One proposal to solve this problem is ''the coordination method''.〔 This is a three-step method to overcome the obstacles of integrating different views and coordinating multiple languages. The method prescribes how to (1) identify and (2) specify the references across language boundaries, that is the ''overlaps'' between different languages. Finally, the method offers concrete proposals on how to (3) apply this knowledge in actual development in the form of consistency, navigation, and guidance. == Motivating example == Enterprise systems based on multiple domain-specific languages are abundant. Languages with a metamodel defined in the Extensible Markup Language (XML) enjoy particularly widespread adoption. To illustrate development with multiple languages, we will draw an example from a case study: (The Apache Open For Business (OFBiz) ) system. Briefly stated, (OFBiz ) is an enterprise resource planning system that includes standard components such as inventory, accounting, e-commerce etc. These components are implemented by a mixture of XML-based languages and regular Java code. As an example, let us focus on the content management component, particularly a use case in which the administrative user creates an online web survey as shown in the screenshot below. We will refer to this example as the ''create survey'' example. File:CreateSurvey-screen.png The figure shows a screenshot of the administrative interface of the content management application in a running (OFBiz ) instance. To create a survey, the user fills out the fields of the input form and hits the ''update'' button. This creates a new survey which can be edited and later published on a frontend website in (OFBiz ). Behind the scenes, this use case involves several artifacts written in different languages. In this example, let us focus on only three of these languages: the Entity, the Service, and the Form DSL. These three languages correspond roughly to the structural, the behavioural, and the user interface concern in (OFBiz ). The Entity DSL is used to describe the underlying data model and hence the way the created survey will be saved. The Service DSL is used to describe the interface of the service that is invoked when the user hits the ''update'' button. Finally, the Form DSL is used to describe the visual appearance of the form. Although the three languages are tailored for different things, they can not be separated entirely. The user interface invokes a certain application logic and this application logic manipulates the data of the application. This is an example of ''non-orthogonal concerns''. The languages overlap because the concerns that they represent cannot be separated entirely. Let us examine these three languages in a bottom-up manner and point out their overlaps. 抄文引用元・出典: フリー百科事典『 ウィキペディア（Wikipedia）』 ■ウィキペディアで「Domain-specific multimodeling」の詳細全文を読む スポンサード リンク
|
